[Backport v4.1-branch] net: dhcpv4: Fixes for Pad option handling and Request message xid value #89668
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In case the received DHCP message is malformed and contains invalid message type, the code responsible for matching message type with a string would assert. This shouldn't be the case that external conditions (like receiving malformed packet) trigger asserts in the system. Therefore modify that code, to return "invalid" string in such case instead. Signed-off-by: Robert Lubos <[email protected]> (cherry picked from commit f4408c0)
Pad option (option code 0) can be present in between other options for alignment. The option has a fixed 1-byte length (i. e. no length field), therefore it did not fall under the common processing code for unrecognized options (which include the length field at the second byte). Therefore, not processing this option explicitly could disturb other options processing, as the parser would wrongly interpret the next option code as the length field. This commit adds Pad option handling to fix the issue. Signed-off-by: Robert Lubos <[email protected]> (cherry picked from commit 9d54465)
According to RFC 2131, DHCP clients should use the same xid as received in the Offer message when sending DHCP Requests. Therefore, when generating DHCP Request message, the xid value should not be incremented. One vague topic is whether the xid value should be updated when sending Requests from Renewing or Rebinding states, however RFC makes no exception for those states, and other implementations (dhclient, lwip) seem to reuse the same xid in such cases, so comply with this behavior. Signed-off-by: Robert Lubos <[email protected]> (cherry picked from commit 45a1cf7)
Add Pad option to the DHCP packets generated by the fake server, to verify the client processes them correctly. Signed-off-by: Robert Lubos <[email protected]> (cherry picked from commit eabeb84)
According to RFC 2131 Request message Exchange ID should be the same as the one received in the Offer message from the server. Modify test to verify that. Signed-off-by: Robert Lubos <[email protected]> (cherry picked from commit 1c46508)
rlubos
approved these changes
May 8, 2025
jukkar
approved these changes
May 8, 2025
maass-hamburg
approved these changes
May 8, 2025
|
kartben
approved these changes
Jun 3, 2025
Author
|
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport 1c46508~5..1c46508 from #89534.
Fixes #89641